Field of the Invention
The present invention relates to the field of network computing. In particular, the present invention relates to a method and respective system for configuring an application program during its deployment in a network ready to be accessed by a remote client application via a network protocol such as TCP/IP, wherein an application server processes a plurality of application components, and wherein the application program is based on an application template comprising the executable code of the application program, which template is configurable at least in part by an end-user by specifying a plurality of user-specific data defining the user-specific attributes adapting the application program to the needs of a specific end-user, for generating a user-specific application runtime instance.
Related Art
With reference to FIG. 1, there is illustrated the basic structural components of a prior art application server. The application server 10 (e.g., IBM WebSphere) is a software program executed on a server computer on a computer network dedicated to running certain software applications accessible by a client application via a network access.
The application server 10 provides a runtime environment for these applications. It also provides support for deploying an application, managing the resource requirements for an application, ensuring the availability, isolation, and protection of an application from other applications and their resource requirements, and monitoring and securing the application.
Generally, an application shall be understood to comprise one or more application components and to include application code and application resources, such as, for example:                Web applications containing J2EE components such as servlets and JSPs, code that can be executed by the application server, resources such as HTML pages, graphic files, etc.; and        Enterprise applications containing among other things J2EE components such as Enterprise Java Beans (EJBs), executable code, as well as web applications.        
Typically an application server supports different types of application components.
The container, e.g., the web container 18 or the portlet container 20, provides means for executing and invoking an application component and ensures the optimal organization of component instances in memory, controlling the life cycle and caching of state to achieve the highest levels of efficiency and integrity, protecting access to the components, and handling the complexities of communication, distribution, and addressing.
An application can be packaged into an application archive that contains application code, resources, and one or more application deployment descriptors that specify component specific application metadata. The packaging makes it possible to transfer, copy, multiply, clone and exchange the application between computers and to deploy the application to an application server.
Deployment is performed in a dedicated software component 16. This comprises basically the step of installing the application on the target application server, which includes configuration steps if necessary, and making that application available for execution. Deployment adds the application to the application server repository and adapts the application server configuration. Typically deployment is initiated by a human deployer (a user or an administrator) by use of a user interface 12 or an input file containing the relevant deployment options. The application server may also offer a deployment API 14 by which dedicated third party deployment tools may access the deployment functionality.
The deployment functionality establishes the application configuration, i.e., the parameters defining the application installation options and the runtime behavior. The deployment configuration is based on an application deployment descriptor and the settings specified by the deployer during deployment via the user interface or an API (during deployment the deployer may manually change or create selected parameters). The application server will persist this deployment configuration and later on use it during runtime.
Next, a simple example (an application “Email”) is given to improve clarity. The sample application server supports four types of configuration parameters:                Application name;        Application server instance;        Virtual host; and        Context root.These items are parameters relevant for deployment and determine:        The application name that is presented to the user or administrator, e.g., “Email”;        The logical application server instance that executes the application, e.g., “server1”;        The virtual host, an abstraction for the HTTP context where the application is made available to users. For example, a virtual host is associated with an IP port, e.g., port 9080.        The context root determines the URL by which the application is available, e.g., “/email”.        
After deployment, the application is ready to be executed by the application server. That is, the application server may start, run, and finally stop the application on request of an administrator or an application management system. While the application is running, the application server 10 accepts requests for the components of the application and forwards incoming requests to the associated container, i.e., the web container 18 or a portlet container 20. The container then invokes the application component (not depicted) to process the request.
In addition, and with special focus to the present invention, an application server 10 may support the concept of prior art “application templates.” An application template itself cannot be executed by the application server directly. In contrast, it can be instantiated into one or multiple applications by users. The application template contains application template configuration, application components, executable code and resources. It may include points of variability (POV), which are customizable, thus user-specific data elements that are filled-in during instantiation. Normally, an administrator or a user performs instantiation of an application template, thereby creating a new application. The application configuration of this instance is derived from the application template configuration, and the values of the POVs which are manually specified by the administrator or user, are specific for this instance.
The POVs of the above sample application template “Email” may include, for example:                User name;        User information (department number, address, etc.);        User location;        Time zone;        Email-address; and        Email-Server.        
A user may instantiate the EMail application template by firstly choosing the template in the user interface and secondly specifying the values for the POVs. Thus, a specific application instance is created and configured for this user which contains his personal configuration for name, user information, location, time zone, email address, and email server.
The technical problem underlying to the present invention will now be described.
The above described application deployment and application template instantiation are highly critical processes since they change the application configuration and establish the application runtime behavior. In the prior art, these steps, specifying the application configuration, providing concrete values for the POVs, etc., are performed manually by an administrator or user. This provokes disadvantageously errors in configuration resulting in that the application will not or not properly operate.
Even if an administrator is allowed to manually specify default values or verification rules for configuration parameters and to verify supplied configuration parameters against these values or rules, this represents a serious burden in terms of effort and thus costs in an environment in which a large plurality of applications or of template instances must be configured, which is the case in many enterprise networks. The reason is that this verification must be done manually by respective highly skilled staff.
Requiring a human to manually specify validation rules is already quite difficult and error-prone, since the design of verification rules is highly complex, as the rules have to be precise enough to differentiate correct and incorrect configuration parameters, in particular for cases where a configuration may be highly personalized and specific for a certain system environment.
Therefore, the prior art does not disclose recommendation and verification programs including functions that build on these techniques and help the user or administrator in configuring an application and avoid misconfiguration. Further, disadvantageously, there also is no support in the prior art for fully automatic configuration in an autonomic on-demand scenario.
This problem will only increase in the future, when the application template concept becomes more and more pervasive. Template instantiation must then be performed by end users, who do not have profound administration skills. Without functions for verification incorporated into the application server, this will create software problems and increase software support and helpdesk costs.